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Foreword 



id , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document describes the network interworking for the Packet Domain. Interworking to various external 
networks is defined together with the interworking for data forwarding while subscribers roam within the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document defines the requirements for Packet Domain interworking between a: 

a) PLMNandPDN; 

b) PLMNandPLMN. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] 3GPP TS 01.04: "Digital cellular telecommunication system (Phase 2+); Abbreviations and 
acronyms". 

[2] 3GPP TS 22.060: "3rd Generation Partnership Project: Technical Specification Group Services 

and System Aspects; General Packet Radio Service (GPRS): Stage 1 Service Description". 

[3] 3GPP TS 23.060: "3rd Generation Partnership Project: Technical Specification Services and 

System Aspects; General Packet Radio Service (GPRS); Service Description Stage 2". 

[4] 3GPP TS 03.61: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Point to Multipoint Multicast Service Description; Stage 2". 

[5] 3GPP TS 03.62: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Point to Multipoint Group Call Service Description; Stage 2". 

[6] 3GPP TS 03.64: "Digital cellular telecommunications system (Phase 2+);General Packet Radio 

Service (GPRS); Overall description of the Radio interface; Stage 2". 

[7] 3GPP TS 04.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control / 
Medium Access Control (RLC/MAC) protocol". 

[8] 3GPP TS 04.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Logical Link Control (LLC)". 

[9] 3GPP TS 24.065: "3rd Generation Partnership Project: Technical Specification Group Core 

Network; General Packet Radio Service (GPRS); Mobile Station (MS) - Serving GPRS Support 
Node(SGSN); Subnetwork Dependent Convergence Protocol (SNDCP)". 

[10] 3GPP TS 27.060: "3rd Generation Partnership Project: Technical Specification Group Core 

Network; Packet Domain; Mobile Station (MS) supporting Packet Switched Services". 

[II] ITU-T Recommendation E. 1 64: "Numbering plan for the ISDN era" . 
[12] <VOID> 

[13] <VOID> 

[14] <VOID> 

[15] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6). 
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[16] IETF RFC 791 (1981): "Internet Protocol" (STD 5). 

[17] IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5). 

[18] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7). 

[19] IETF RFC 1034 (1987): "Domain Names - Concepts and Facilities" (STD 7). 

[20] <VOID> 

[21] IETF RFC 1661 and 1662 (1994): "The Point-to-Point Protocol (PPP)" (STD 51). 

[22] IETF RFC 1700 (1994): "Assigned Numbers" (STD 2)3. 

[23] UMTS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols - Stage 3". 

[24] UMTS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across 

the Gn and Gp Interface". 

[25] IETF RFC2794 (2000), Pat R. Calhoun and Charles E. Perkins: "Mobile IP Network Address 

Identifier Extension for IPv4", March 2000. 

[26] IETF RFC 2131 (1997): "Dynamic Host Configuration Protocol". 

[27] IETF RFC 1542 (1993): "Clarification and Extensions for the Bootstrap Protocol". 

[28] IETF RFC2373 (1998): "IP version 6 Addressing Architecture". 

[29] IETF RFC 2462 (1998): "IPv6 Stateless Address Autoconfiguration". 

[30] IETF RFC 2002 (1996), C. Perkins: "IP Mobility Support". 

[31] IETF RFC 2486 (1999), B. Aboba and M. Beadles: "The Network Access Identifier". 

[32] IETF RFC1 1 12 (1989), S.E. Deering: "Host extensions for IP multicasting". 

[33] IETF RFC2236 (1997), W. Fenner: "Internet Group Management Protocol, Version 2". 

[34] IETF RFC2362 (1998), D. Estrin and al: "Protocol Independent Multicast-Sparse Mode 

(PIM-SM)". 

[35] IETF RFC1075 (1988), D. Waitzman and al: "Distance Vector Multicast Routing Protocol". 

[36] IETF RFC1585 (1994), J. Moy: "MOSPF".. 

[37] IETF RFC2290 (1998), J. Solomon, S. Glass: "Mobile-IPv4 Configuration Option for PPP IPCP " 

[38] IETF RFC2865 (2000), C. Rigney, S. Willens, A. Rubens, W. Simpson: "Remote Authentication 

Dial In User Service (RADIUS)". 

[39] IETF RFC2866 (2000), C. Rigney, Livingston: " RADIUS Accounting ". 

[40] 3GPP TS 23.003: "3rd Generation Partnership Project; Technical Specification Group Core 

Network; Numbering, addressing and identification". 

3 Definitions, abbreviations and symbols 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in UMTS 22.060 and 
UMTS 23.060 and the following apply: 
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2G- / 3G-: prefixes 2G- and 3G- refers to functionality that supports only GSM GPRS or UMTS, respectively, e.g., 
2G-SGSN refers only to the GSM GPRS functionality of an SGSN. When the prefix is omitted, reference is made 
independently from the GSM GPRS or UMTS functionality. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

APN Access Point Name 

ATM Asynchronous Transfer Mode 

BG Border Gateway 

CHAP Challenge Handshake Authentication Protocol 

DHCP Dynamic Host Configuration Protocol 

DNS Domain Name System 

DVMRP Distance Vector Multicast Routing Protocol 

GGSN Gateway GPRS Support Node 

GTP-U GPRS Tunnelling Protocol for user plane 

ICMP Internet Control Message Protocol 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

IP Internet Protocol 

IPv4 Internet Protocol version 4 

IPv6 Internet Protocol version 6 

ISDN Integrated Services Digital Network 

ISP Internet Service Provider 

LAC L2TP Access Concentrator 

LAN Local Area Network 

LNS L2TP Network Server 

MIP Mobile IP 

MOSPF Multicast Open Shortest Path First 

MS Mobile Station 

MT Mobile Terminal 

MTU Maximum Transfer Unit 

NAI Network Access Identifier 

PAP Password Authentication Protocol 

PDCP Packet Data Convergence Protocol 

PDN Packet Data Network 

PDU Protocol Data Unit 

PIM-SM Protocol Independant Multicast - Sparse Mode 

PPP Point-to-Point Protocol 

PS Packet Switched 

RADIUS Remote Authentication Dial In User Service 

SGSN Serving GPRS Support Node 

SMDS Switched Multimegabit Data Service 

TCP Transmission Control Protocol 

TE Terminal Equipment 

TEID Tunnel End-point Identifier 

UDP User Datagram Protocol 



3.3 Symbols 



For the purposes of the present document, the following symbols apply: 



Gb 

Gi 
Gn 
Gp 

Gs 
lu 



Interface between an SGSN and a BSC. 

Reference point between Packet Domain and an external packet data network. 

Interface between two GSNs within the same PLMN. 

Interface between two GSNs in different PLMNs. The Gp interface allows support of Packet 

Domain network services across areas served by the co-operating PLMNs. 

Interface between an SGSN and MSC. 

Interface between the RNS and the core network. It is also considered as a reference point. 
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R The reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 
Um The interface between the MS and the GSM fixed network part. The Um interface is the GSM 

network interface for providing packet data services over the radio to the MS. The MT part of the 

MS is used to access the GSM services through this interface. 
Uu Interface between the mobile station (MS) and the UMTS fixed network part. The Uu interface is 

the UMTS network interface for providing packet data services over the radio to the MS. The MT 

part of the MS is used to access the UMTS services through this interface. 



4 Network characteristics 

4.1 Key characteristics of PLMN 

The PLMN is fully defined in the UMTS technical specifications. The Packet Domain related key characteristics are 
found in 3GPP TS 22.060 and 3GPP TS 23.060. 

4.2 Key characteristics of PSDN 

<VOID> 

4.3 Key characteristics of IP Networks 

The Internet is a conglomeration of networks utilising a common set of protocols. IP protocols are defined in the 
relevant IETF STD specifications and RFCs. The networks topologies may be based on LANs (e.g. ethernet), Point to 
Point leased lines, PSTN, ISDN, X.25 or WANs using switched technology (e.g. SMDS, ATM). 



5 Interworking Classifications 

5.1 Service Interworking 

Service interworking is required when the Teleservice at the calling and called terminals are different. For Packet 
Domain, service interworking is not applicable at the Gi reference point. 



5.2 Network Interworking 



Network interworking is required whenever a PLMN is involved in communications with another network to provide 
end-to-end communications. The PLMN shall interconnect in a manner consistent with that of a normal Packet Data 
Network (type defined by the requirements e.g. IP). Interworking appears exactly like that of Packet Data Networks. 

5.3 Numbering and Addressing 

See 3GPP TS 23.003 and the relevant section for IP addressing below. 



Access reference configuration 



Figure 1 shows the relationship between the MS, its terminal equipment and the UMTS/GSM network in the overall 
Packet Domain environment. 
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reference point 




Figure 1 : Packet Domain Access Interfaces and Reference Points 



Interface to Packet Domain Bearer Services 



7.1 



GSM 



The following figure 2a shows the relationship of the GSM Packet Domain Bearer terminating at the SNDCP layer to 
the rest of the GSM Packet Domain environment. It is shown for reference purposes only and detailed information can 
be found in 3GPP TS 23.060. 
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Figure 2a: User Plane for Packet Domain services in GSM 



7.2 



UMTS 



The following figure 2b shows the relationship of the UMTS Packet Domain Bearer, terminating at the PDCP layer, to 
the rest of the UMTS Packet Domain environment. It is shown for reference purposes only and detailed information can 
be found in 3GPP TS 23.060. 
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Figure 2b: User Plane for Packet Domain services in UMTS 



8 Subscription checking 



Subscription is checked during the PS Attach procedure and also during the PDP Context Activation procedure as 
described in 3GPP TS 23.060. The GGSN implicitly checks its internal context related to the destination address for 
each mobile terminated packet. If there is a context associated with the PDP address the packet shall be forwarded to the 
MS, otherwise the packet shall be discarded or rejected depending on the implemented protocol. 



Message Screening 



Screening functions reside within the Packet Domain as described in 3GPP TS 22.060 and 3GPP TS 23.060. Screening 
may be applicable for only certain protocols. Screening is outside the scope of the present document. 



10 Interworking with PSDN (X.75/X.25) 

<VOID> 



1 1 Interworking with PDN (IP) 
11.1 General 

Packet Domain shall support interworking with networks based on the Internet Protocol (IP). These interworked 
networks may be either intranets or the Internet. 



1 1 .2 PDN Interworking Model 



When interworking with the IP networks, the Packet Domain can operate IPv4 or Ipv6. The interworking point with IP 
networks is at the Gi reference point as shown in figure 7. 
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Packet Domain 
Network 



Figure 7: IP network interworking 

The GGSN for interworking with the IP network is the access point of the Packet Domain (see figure 8). In this case the 
Packet Domain network will look like any other IP network or subnetwork. 
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Figure 8: The protocol stacks for the IP / Gi reference point 

Typically in the IP networks, the interworking with subnetworks is done via IP routers. The Gi reference point is 
between the GGSN and the external IP network. From the external IP network's point of view, the GGSN is seen as a 
normal IP router. The L2 and LI layers are operator specific. 

It is out of the scope of the present document to standardise the router functions and the used protocols in the Gi 
reference point. 

Interworking with user defined ISPs and private/public IP networks is subject to interconnect agreements between the 
network operators. 

No user data or header compression is done in the GGSN. 

1 1 .2.1 Access to Internet, Intranet or ISP through Packet Domain 

The access to Internet, Intranet or ISP may involve specific functions such as : user authentication, user's authorization, 
end to end encryption between MS and Intranet/ISP, allocation of a dynamic address belonging to the 
PLMN/Intranet/ISP addressing space, etc. 

For this purpose the Packet Domain may offer: 

either direct transparent access to the Internet; or 
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a non transparent access to the Intranet/ISP. In this case the Packet Domain, i.e. the GGSN, takes part in the 
functions listed above. 

The mechanisms for host configuration and user authentication described in this section and its sub-sections are only 
applicable to the activation of the first context activated for a specific PDP address (using the 'PDP Context Activation 
Procedure'). The activation of any subsequent PDP contexts for that PDP address, using the 'Secondary PDP Context 
Activation Procedure', as well as the use of TFTs, is described in 3GPP TS 23.060. 



1 1 .2.1 .1 Transparent access to the Internet 

Gi 
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Firewall / 
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/External IP \ 
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Figure 9: Example of the PDN Interworking Model, transparent case 

In this case (see figure 9): 

the MS is given an address belonging to the operator addressing space. The address is given either at 
subscription in which case it is a static address or at PDP context activation in which case it is a dynamic 
address. This address is used for packet forwarding between the Internet and the GGSN and within the GGSN. In 
IPv6, the address given is the link-local address. Thus, for the IPv6 it is not necessary to use a DHCP 
implementation for the address allocation, but any unique identifier for the MS in the GGSN is sufficient; 

the MS need not send any authentication request at PDP context activation and the GGSN need not take any part 
in the user authentication/authorization process. 

The transparent case provides at least a basic ISP service. As a consequence of this it may therefore provide a bearer 
service for a tunnel to a private Intranet. 

NB The remainder of this subclause deals with this specific case. 

The user level configuration may be carried out between the TE and the intranet, the Packet Domain network is 
transparent to this procedure. 

The used protocol stack is depicted in figure 10. 
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Figure 10: Transparent access to an Intranet 

The communication between the PLMN and the Intranet may be performed over any network, even an insecure network 
e.g. the Internet. There is no specific security protocol between GGSN and the Intranet because security is ensured on 
an end to end basis between MS and the intranet by the «Intranet protocols 
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User authentication and encryption of user data are done within the «Intranet protocol» if either of them is needed. This 
«Intranet protocol» may also carry private (IP) addresses belonging to the address space of the Intranet. 

An example of an «Intranet protocol» is IPsec (see RFC 1825). If IPsec is used for this purpose then IPsec 
authentication header or security header may be used for user (data) authentication and for the confidentiality of user 
data (see RFC 1826 and RFC 1827). In this case private IP tunnelling within public IP takes place. 



11.2.1.2 

In this case: 



Non Transparent access to an Intranet or ISP 



the MS is given an address belonging to the Intranet/ISP addressing space. The address is given either at 
subscription in which case it is a static address or at PDP context activation in which case it is a dynamic 
address. This address is used for packet forwarding within the GGSN and for packet forwarding on the 
Intranet/ISP. This requires a link between the GGSN and an address allocation server, like Radius, DHCP, ..., 
belonging to the Intranet/ISP; 

the MS shall send an authentication request at PDP context activation and the GGSN requests user authentication 
from a server, like Radius, DHCP, ..., belonging to the Intranet/ISP; 

the protocol configuration options are retrieved (if requested by the MS at PDP context activation) from some 
server (Radius or DHCP, ...) belonging to the Intranet/ISP; 

the communication between the Packet Domain and the Intranet/ISP may be performed over any network, even 
an insecure e.g. the Internet. In case of an insecure connection between the GGSN and the Intranet/ISP there 
may be a specific security protocol in between. This security protocol is defined by mutual agreement between 
PLMN operator and Intranet/ISP administrator. 
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Figure 11a: Signalling plane of non transparent case 

The following description bullet items describe the signal flow. 

1) The TE sends an AT-command to the MT to set up parameters and enter PPP mode. The MT responds with an 
AT-response. 

2) LCP negotiates Maximum-Receive-Unit and authentication protocol. The negotiated authentication protocol is, 
either CHAP, PAP or 'none'. The MT shall try to negotiate for CHAP as first priority. 

3) If the negotiated authentication protocol is either of CHAP or PAP, the TE authenticates itself towards the MT 
by means of that protocol. The MT stores the necessary authentication data and sends a forced positive 
acknowledgement of the authentication to the TE. 

4) The TE requests IP configuration by sending the IPCP Configure-Request message to the MT indicating either 
the static IP address that shall be used or that an IP-address shall be dynamically allocated. 

5) The MT sends the Activate PDP context request message to the SGSN, including the Protocol Configuration 
Options. The SGSN sends the Create PDP context req message to the chosen GGSN including the unmodified 
Protocol Configuration Options. 

6) The GGSN deduces from the APN: 
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the server(s) to be used for address allocation, authentication and protocol configuration options retrieval; 

the protocol like Radius, DHCP, ... to be used with this / those server(s); 

the communication and security feature needed to dialogue with this / those server(s) e.g. tunnel, IPSec 
security association, dial-up connection (using possibly PPP), . . . 

As an example the GGSN may use one of the following options: 

RADIUS for authentication and IP-address allocation.. The RADIUS server responds with either an Access- 
Accept or an Access-Reject to the RADIUS client in the GGSN; 

RADIUS for authentication and DHCP for host configuration and address allocation. The RADIUS server 
responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN. After a 
successful authentication, the DHCP client discovers the DHCP server(s) in the ISP/Intranet and receives 
host configuration data. 

If the received Protocol Configurations Options IE contains a PPP IPCP Configure-Request packet, the GGSN 
shall analyse all the contained IPCP options and their requested values. In accordance with the relevant PPP [20] 
the GGSN shall respond with the following messages: 

- zero or one PPP IPCP Configure-Reject packet containing options not supported and options which values 
cannot be returned; 

zero or one PPP IPCP Configure-Nak packet containing options that are supported but has requested values 
that are incorrect/unsupported; and 

zero or one PPP IPCP Configure- Ack packet containing options that are supported and has requested values 
that are correct/supported. 

Any returned PPP IPCP packets shall be contained in the Protocol Configurations Options IE. 

7) The GGSN sends back to the SGSN a Create PDP Context Response message, containing the Protocol 
Configuration Options IE. The cause value shall be set according to the outcome of the host -authentication and - 
configuration. . A PDP context activation shall not be rejected solely due to the presence of unsupported or 
incorrect PPP IPCP options or option values, received from the MS in the Protocol Configurations Options IE. 
The MS may however later decide to immediately deactivate the activated PDP context due to the information 
received in the Protocol Configurations Options IE received from the network. 

8) Depending on the cause value received in the Create PDP Context Response the SGSN sends either an Activate 
PDP Context Accept or an Activate PDP Context Reject, to the MS. 

If Protocol Configuration Options are received from the GGSN, the SGSN shall relay those to the MS. The MT 
sends either the configuration-ack packet (e.g. IPCP Configure Ack in PPP case), the configure-nack packet in 
case of dynamic address allocation (e.g. IPCP Configure Nack in PPP case), or a link Terminate request (LCP 
Terminate-Request in PPP case) back to the TE. In the case where a configure-nack packet was sent by the MT, 
a local negotiation may take place at the R reference point (i.e. the TE proposes the new value to the MT), after 
which a configuration-ack packet is sent to the TE. 

9) In case a configuration-ack packet was sent to the TE, the link from the TE to the external ISP/Intranet is 
established and IP packets may be exchanged. 

In case a link terminate request packet was sent to the TE, the TE and MT negotiates for link termination. The 
MT may then send a final AT-response to inform the TE about the rejected PDP Context activation. 

A link terminate request packet (such as LCP Terminate-request in PPP case) causes a PDP context deactivation. 

EXAMPLE: In the following example PPP is used as layer 2 protocol over the R reference point. 

The MT acts as a PPP server and translates Protocol Configuration Options into SM message IEs. GTP-C carries this 
information unchanged to the GGSN which uses the information e.g. for DHCP or RADIUS authentication and host 
configuration. The result of the host authentication and configuration is carried via GTP-C to the SGSN which relays 
the information to the MT. The MT sends an IPCP Configure- Ack to the TE with the appropriate options included. 
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Figure 11b: PDP Context Activation for the Non-transparent IP case 
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1 1 .2.1 .3 Access to Internet, Intranet or ISP with Mobile IPv4 

General 

A way to allow users to roam from one environment to another, between fixed and mobile, between public and private 
as well as between different public systems is to use Mobile IP [30]. Mobile IP (MIP) is a mobility management 
protocol developed by IETF. The Mobile IP Foreign Agent (FA) [30] is located in the Core Network in the GGSN. MIP 
also uses a Home Agent (HA) [30] which may or may not be located in a GSM/UMTS network. 

Interworking model for MIP 

A FA is located in the GGSN. The interface between the GGSN and the FA will probably not be standardised as the 
GGSN/FA is considered being one integrated node. The mapping between these two is a matter of implementation. 
Each FA must be configured with at least one care-of address. In addition a FA must maintain a list that combines IP 
addresses with TEIDs of all the visiting MSs that have registered with the FA. IP packets destined for the MS are 
intercepted by the HA and tunneled to the MS's care-of address, i.e. the FA. The FA de-tunnels the packets and 
forwards the packets to the MS. Mobile IP related signalling between the MS and the FA is done in the user plane. MIP 
registration messages [30] are sent with UDP. 
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Figure 11c: The protocol stacks for the Gi IP reference point in the MIP signalling plane 
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Figure 11d: Protocol stacks for user access with MIP 

In figure 1 Id: "(Tunneling)" is intended to show asymmetric traffic flow. Tunneling (IP-in-IP) is only used in the 
direction from the ISP towards the MT. 

Authentication of the user is supported in Mobile IPv4. This authentication mechanism may involve communication 
with an authentication server (e.g. RADIUS), although this is not shown in figure lid. 
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Address allocation - at PDP context activation no IP address is allocated to the MS indicated by 0.0.0.0. in the 
"Requested PDP Address" field. If the MS does not have a static IP address which it could register with the HA, it will 
acquire a dynamic IP address from the HA [25]. After completion of the PDP activation the SGSN is informed of the 
assigned IP address by means of the GGSN initiated PDP Context Modification Procedure. 

An example of a signalling scheme, shown in figure 1 le, is described below. In this example the MS is separated into a 
TE and MT, with AT commands and PPP used in-between (see 3GPP TS 27.060). The PS attach procedures have been 
omitted for clarity. 
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Figure 11e: Example of PDP Context activation with Mobile IP registration (the PS attach procedure 

not included) 

1 . The AT command carries parameters that the MT needs to request the PDP Context Activation. The important 
parameter here, is the APN (Access Point Name), see clause A below. The AT command is followed by a setup 
of the PPP connection between the MT and the TE. 

2. As part of the PPP connection, LCP negotiates Maximum-Receive-Unit between the TE and the MT. No PPP 
authentication is required when using MIPv4. 

3. As part of the PPP connection, the TE sends an IPCP Configure Request using the MIPv4 configuration option 
(see [37]). The TE sends either its Home Address or a null address (i.e. 0.0.0.0) if the Network Address identifier 
is used (see [25]). 

4. The MT sends the "Activate PDP Context Request" to the SGSN. The message includes various parameters of 
which the "APN" (Access Point Name) and the "Requested PDP Address" are of interest here. The TE/MT may 
use APN to select a reference point to a certain external network or to select a service. APN is a logical name 
referring to the external packet data network or to a service that the subscriber wishes to connect to. The 
"Requested PDP Address" should be omitted for all MS's using Mobile IP. This is done irrespective of if the TE 
has a permanently assigned Mobile IP address from its Mobile IP home network, a previously assigned dynamic 
home address from its Mobile IP home network or if it wishes the Mobile IP home network to allocate a "new" 
dynamic home address. 
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A. The SGSN will base the choice of GGSN based on the APN that is given by the MS. 

5. The SGSN requests the selected GGSN to set up a PDP Context for the MS. The PDP address and APN fields 
are the same as in the "Activate PDP Context Request" message. 

6. A Create PDP Context Response is sent from the GGSN/FA to the SGSN. If the creation of PDP Context was 
successful, some parameters will be returned to the SGSN, if not, an error code will be returned. If the GGSN 
has been configured, by the operator, to use a Foreign Agent for the requested APN, the PDP address returned by 
the GGSN shall be set to 0.0.0.0. indicating that the PDP address shall be reset by the MS with a Home Agent 
after the PDP context activation procedure. 

7. The Activate PDP Context Accept message is sent by the SGSN to the MT and contains similar information as 
the Create PDP Context Response message. 

8. The MT sends an IPCP Configure Ack to the TE in order to terminate the PPP connection phase. 

9. The Agent Advertisement [30] is an ICMP (Internet Control Message Protocol) Router Advertisement message 
with a mobility agent advertisement extension. The latter part contains parameters of the FA that the mobile 
node needs, among those are one or more care-of addresses that the FA offers. This message should be sent, in 
the Packet Domain user plane, as an IP limited broadcast message, i.e. destination address 255.255.255.255, 
however only on the TEID for the requesting MS to avoid broadcast over the radio interface. 

10. The Mobile IP Registration Request is sent from the mobile node to the GGSN/FA across the Packet Domain 
backbone as user traffic. The mobile node includes its (permanent) home address as a parameter [30]. 
Alternatively, it can request a temporary address assigned by the home network by sending 0.0.0.0 as its home 
address, and include the Network Access Identifier (NAI) in a Mobile-Node-NAI Extension [25], [31]. 

1 1 . The FA forwards the Mobile IP Registration Request to the home network of the mobile node, where a home 
agent (HA) processes it. Meanwhile, the GGSN/FA needs to store the home address of the mobile node or the 
NAI and the local link address of the MS, i.e. the TEID (Tunnel Endpoint ID). 

12. The Registration Reply is sent from the home network to the FA, which extracts the information it needs and 
forwards the message to the mobile node in the Packet Domain user plane. As the FA/GGSN knows the TEID 
and the NAI or home address, it can pass it on to the correct MS. 

B. The GGSN/FA extracts the home address from the Mobile IP Registration Reply message and updates its GGSN 
PDP Context. 

13. The GGSN triggers a "GGSN initiated PDP Context modification procedure" in order to update the PDP address 
in the SGSN and in the MT. 



11.3 Numbering and Addressing 



In the case of interworking with public IP networks (such as the Internet), the PLMN operator shall use public network 
addresses. These public addresses can be reserved from the responsible IP numbering body, or from an ISP with which 
the PLMN operator has an agreement. 

In the case of interworking with private IP networks, two scenarios can be identified: 

1. the GPRS operator manages internally the subnetwork addresses. Each private network is assigned a unique 
subnetwork address. Normal routing functions are used to route packets to the appropriate private network; 

2. each private network manages its own addressing. In general this will result in different private networks having 
overlapping address ranges. A logically separate connection (e.g. an IP in IP tunnel or layer 2 virtual circuit) is 
used between the GGSN and each private network. In this case the IP address alone is not necessarily unique. 
The pair of values, Access Point Name (APN) and IP address, is unique. 

The PLMN operator allocates the IP addresses for the subscribers in either of the following ways. 

The PLMN operator allocates a static IP address when the subscription record is built. The IP address is reserved 
from a pool of free IP addresses. Each external network has its own pool of addresses. 
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The PLMN operator allocates (either on its own or in conjunction with the external network) a dynamic IP 
address when the MS performs the PDP Context Activation procedure with dynamic address allocation as 
described in 3GPP TS 23.060. 

11.4 Charging 

The PLMN operator may define the accuracy of the charging mechanism using one of the following categories: 

every source/destination pair is logged separately; 

source/destination pairs are logged to an accuracy of subnetworks; 

source/destination pairs are logged to an accuracy of connection types (e.g., external data network, corporate 
network, another mobile). 

1 1 .5 Domain Name System Server (DNS Server) 

Provision of Domain Name services shall be provided by the PLMN operators in the transparent case and the ISP in the 
non transparent case. (DNS documentation is provided in RFC 1034 and RFC 1035). 



11.6 Screening 



The way the PLMN is performing the operator controlled screening and the subscription controlled screening is out of 
the scope of the present document. These functions may be done, for example, in a firewall. 

1 1 .7 IP Multicast access 

The Packet Domain could allow access to IP Multicast traffic coming from an external network. The support of 
IP -Multicast in the Packet Domain is optional. 

In order for the Packet Core Network to support Multicast traffic that will allow the MS to subscribe to multicast groups 
from outside the PLMN, the GGSN shall support IGMP and one or more Inter-Router Multicast protocols, such as 
DVMRP, MOSPF, or PIM-SM. 

IGMP is an integral part of IP. All hosts wishing to receive IP multicasts are required to implement IGMP (or 
equivalent) and class-D IP addresses. IGMP messages are encapsulated in IP datagrams. 

To be able to deliver IP-Multicast packets to the appropriate TEs, the GGSN may have an IP-Multicast proxy 
functionality. 

The IP-Multicast proxy will perform the following tasks: 

NOTE: In this example it is assumed that IGMP is used as a Host-Router Multicast protocol. 

maintain a list of mobiles that joined one or more Multicast groups. This list is built/updated each time the 
GGSN receives an IGMP Join Message from the mobile; 

send, based on this maintained list of mobiles, multicast routing information to the routers attached to the Packet 
Domain, allowing them to route multicast packets; 

upon reception by the GGSN of multicast packets, make and send a copy as Point-to-Point packets, to each 
mobile of the group. 

IP -Multicast traffic can only be handled after an MS has attached to the Packet Domain, and Activated PDP context(s) 
(including possibly authentication) to the preferred ISP/external network. The Multicast traffic is handled at the 
application level from a Packet Domain perspective and is sent over UDP/IP. 

The following figure 12 depicts the protocol configuration for handling Multicast traffic (control plane). The Multicast 
traffic handling affects the GGSN by the introduction of the IP-Multicast proxy and the support for an Inter-Router 
Multicast protocol and a host-router multicast protocol. 
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Figure 12: Protocol configuration for IP-Multicast handling (control plane) 



12 Interworking with PDN (PPP) 



12.1 General 



By means of the PDP type 'PPP' Packet Domain may support interworking with networks based on the point-to-point 
protocol (PPP), as well as with networks based on any protocol supported by PPP through one of its Network Control 
Protocols (NCPs). All protocols currently supported by PPP NCP's are listed in [21]. It may also support interworking 
by means of tunnelled PPP, by e.g. the Layer Two Tunnelling Protocol (L2TP). 



12.2 PDN Interworking Model 



The interworking point is at the Gi reference point. The GGSN for interworking with the ISP/PDN is the access point of 
the Packet Domain (see figure 13). The GGSN will either terminate the PPP connection towards the MS or may further 
relay PPP frames to the PDN. The PPP frames may be tunnelled in e.g. L2TP. 
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Figure 13: The protocol stacks for the Gi PPP reference point 
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In case the external PDN is an IP based network and the GGSN terminates PPP the same description applies as 
specified in subclause 11.2. 

In case the GGSN tunnels PPP frames to the PDN, the GGSN may behave like a LAC towards the external network. 

12.2.1 Virtual dial-up- and direct Access to PDNs, or ISPs through Packet 
Domain 

The access to PDNs, or ISPs may involve specific functions such as: user authentication, user's authorization, end to 
end encryption between MS and PDN/ISP, allocation of a dynamic address belonging to the PLMN/PDN/ISP 
addressing space, etc. 

For this purpose the PLMN may offer, based on configuration data: 

direct access to an IP based Intranet/ISP using a protocol configuration as depicted in figure 14. Here DHCP 
and/or RADIUS are used between the GGSN and Intranet/ISP for performing the specific functions mentioned 
above. The Packet Domain may also offer access to networks based on any protocol supported by PPP through 
one of its Network Control Protocols (NCPs); 
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Figure 14: Protocol stack for direct access to IP-based Intranets/ISPs 

virtual dial-up access to a PDN with PPP frame tunnelling as depicted in figure 15. 
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Figure 15: Protocol stack for virtual dial-up access with PPP frame tunnelling 



Procedural description 



the MS is given an address belonging to the Intranet/ISP addressing space. The address is given either at 
subscription in which case it is a static address or at PDP context activation in which case it is a dynamic 
address. This address is used for packet forwarding within the GGSN and for packet forwarding on the 
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Intranet/ISP. This requires a link between the GGSN and an address allocation server, such as Radius, or DHCP, 
belonging to the Intranet/ISP; 

the communication between the Packet Domain and the Intranet/ISP may be performed over any network, even 
an insecure e.g. the Internet. In case of an insecure connection between the GGSN and the Intranet/ISP there may 
be a specific security protocol in between. This security protocol is defined by mutual agreement between PLMN 
operator and Intranet/ISP administrator. 

The following description bullet items describe the signal flow. 

1) The TE sends an AT-command to the MT to set up parameters. 

2) The MT sends the Activate PDP context request message to the SGSN which sends the Create PDP context 
request message to the chosen GGSN. 

3) The GGSN deduces from the APN: 

the server(s) to be used for address allocation and authentication; 

the protocol such as Radius, DHCP or L2TP to be used with this / those server(s); 

the communication and security feature needed to dialogue with this / those server(s) e.g. tunnel JPSec 
security association, dial-up connection (using possibly PPP). 

As an example the GGSN may use one of the following options: 

RADIUS for authentication and IP-address allocation. The RADIUS server responds with either an Access- 
Accept or an Access-Reject to the RADIUS client in the GGSN; 

RADIUS for authentication and DHCP for host configuration and address allocation. The RADIUS server 
responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN. After a 
successful authentication, the DHCP client discovers the DHCP server(s) in the ISP/Intranet and receives 
host configuration data; 

L2TP for forwarding PPP frames to a L2TP Network Server. 

4) The GGSN sends back to the SGSN a Create PDP Context Response message. 

5) Depending on the cause value received in the Create PDP Context Response the SGSN may either send the 
Activate PDP Context Accept message or send the Activate PDP Context Reject message to the MS. 

6) The MT responds with an AT-response that may indicate whether the context activation was successful or not. In 
the case of a non-successful context activation the response may also indicate the cause. 

In case of a successful context activation, the TE will start its PPP protocol after the LLC link has been 
established. The LCP, Authentication and IPCP (in case of IP) negotiations are then carried out. During these 
negotiations the GGSN may acknowledge values, for any LCP options related to L2' framing (e.g. ACCM', 
ACFC and ECS-Alternatives'), as proposed by the MT, which itself is forwarding these negotiations from the 
TE. 

NOTE: With the <PDP Type>"PPP" the MT may provide a PPP relay (or proxy) function between the TE and 
GGSN. This gives the opportunity for the MT to intercept the L2' framing end to end negotiations. 

EXAMPLE: In the following example the successful PDP context activation is shown. 
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13 Interworking with PDN (DHCP) 
13.1 General 

In current LAN environments the most commonly used configuration protocol is DHCP (Dynamic Host Configuration 
Protocol, [20]). It provides a mechanism for passing a large set of configuration parameters to hosts connected to a 
TCP/IP network (IP address, sub-net mask, domain name, MTU, etc.) in an automatic manner. Moreover DHCP may 
assign IP addresses to clients for a finite lease time, allowing for sequential reassignment of addresses to different users. 

The lease time is chosen by the administrator of the DHCP server (in the external network), and is therefore out of the 
scope of this specification. 

The Packet Domain offers the end user the possibility to run DHCP end-to-end the same way as he does when 
connected directly to a LAN (e.g. an enterprise Intranet). No modifications should be required in common 
implementations of DHCP clients and servers. However a Packet Domain-specific DHCP relay agent [21] is needed in 
the GGSN so as to allow correct routing of DHCP requests and replies between the TE and the DHCP servers. 

At PDP context activation no IP address is allocated, this is done afterwards through DHCP. After the TE's 
configuration has been completed by DHCP, the PDP context is updated by means of the GGSN-initiated PDP Context 
Modification Procedure in order to reflect the newly assigned IP address. 

In the following cases the corresponding PDP context shall be deactivated and the whole procedure starting with PDP 
context activation shall be restarted by the MS 

• if the DHCP lease expires 

• if the DHCP renewal is rejected by the DHCP server 

• if the IP address is changed during the renewal process. Usually when the lease is renewed, the IP address remains 
unchanged. However, if for any reason (e.g. poor configuration of the DHCP server), a different IP address is 
allocated during the lease renewal process the PDP Context shall be deactivated. 
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13.2 PDN Interworking Model for DHCP 

A DHCP relay agent shall be located in the GGSN used for interworking with the IP network as illustrated in the 
following figure 16b. 
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Figure 16b: The protocol stacks for the Gi IP reference point for DHCP 

The DHCP relay agent relays the requests received from the DHCP client to the DHCP server(s), and the replies 
received from the server(s) to the corresponding client. The DHCP relay agent allows for the replies from DHCP 
servers to be delivered to the correct terminal, as the logical connection from the MT terminates in the GGSN, and 
consequently only the GGSN holds enough information to locate the DHCP client. How the DHCP relay agent 
identifies the MT based on the DHCP messages is out of the scope of UMTS standardisation. 

DHCP provides mechanisms for user authentication and integrity protection, but does not offer any message 
confidentiality, therefore additional mechanisms (e.g. IPsec tunnel) may be provided if the link towards the external 
network is not secure. However this is out of the scope of the present document. 

Apart from the particulars mentioned above, this model is basically the same as the one for interworking with IP 
networks described elsewhere in the present document. Using DHCP corresponds to the transparent access case as the 
GGSN does not take part in the functions of authentication, authorisation, address allocation, etc. 

1 3.2.1 Address allocation by the Intranet or ISP 

The MS is given an address belonging to the Intranet/ISP addressing space. The address is given dynamically 
immediately after the PDP context activation. This address is used for packet forwarding between the Intranet/ISP and 
the GGSN and within the GGSN. 

The MS may authenticate itself to the Intranet/ISP by means of the relevant DHCP procedures (DHCP authentication is 
currently described in an Internet Draft). 

The protocol configuration options are retrieved from the DHCP server belonging to the Intranet/ISP. 
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Figure 16c: Protocol stack for access with DHCP end-to-end 

The following description bullet items describe the signal flow. For a detailed description of the DHCP messages refer 
to [26], [27]. The end-to-end protocol configuration is depicted in figure 16c. 

1) The TE and MT exchange several AT commands carrying the QoS and other parameters requested by the TE, 
and requesting the activation of a PDP context of PDP type IP. The TE selects the APN of the configured 
Intranet/ISP offering a DHCP service, or the APN consisting of the Reserved Service Label for DHCP that the 
user has subscribed to. In the latter case the TE will be connected to a PLMN operator-configured service 
provider offering a DHCP service (according to the APN selection rules). 

2) The MT sends the Activate PDP Context Request message to the SGSN with an empty PDP address field. 

3) The SGSN selects a GGSN based on the APN requested by the MS and sends a Create PDP Context Request 
message to that GGSN. The GGSN replies with a Create PDP Context Response message. If the GGSN has not 
been configured by the operator to use external PDN address allocation with DHCP for the requested APN, the 
cause shall be set to 'Service not supported'. No IP address is assigned at this point; the PDP address returned by 
the GGSN is set to 0.0.0.0, indicating that the IP address is not yet assigned and shall be negotiated by the TE 
with the Intranet/ISP after the PDP context activation procedure. 

4) Depending on the cause value received in the Create PDP Context Response the SGSN sends either an Activate 
PDP Context Accept or an Activate PDP Context Reject back to the MT. In case of a successful activation the 
PDP context is established with the PDP address set to 0.0.0.0. 

5) Upon reception of the Activate PDP Context Accept, the MT sends an AT response to the TE that acknowledges 
the completion of the PDP context activation procedure. 

6) The TE sends a DHCPDISCOVER message with the IP destination address set to the limited broadcast address 
(all Is). The GGSN will pass the DHCPDISCOVER to the DHCP relay agent which will relay the request to the 
DHCP server configured for the APN of the PDP context. If more than one DHCP server is configured for a 
given APN, the request will be sent to all of them. The DHCP relay agent will add enough information to the 
DHCPDISCOVER message to be able to relay the replies back to the MS. How this is done is out of the scope of 
UMTS standardisation. 

7) DHCP servers receiving the DHCPDISCOVER request reply by sending a DHCPOFFER message including an 
offered IP address. The DHCP relay agent forwards the replies to the proper MS. 

8) The TE chooses one of the possibly several DHCPOFFERs and sends a DHCPREQUEST confirming its choice 
and requesting additional configuration information. The relay agent relays the DHCPOFFER as explained in 
step 6. 

9) The selected DHCP server receives the DHCPREQUEST and replies with a DHCPACK containing the 
configuration information requested by the TE. The DHCP relay agent relays the DHCPACK to the TE. 

10) The DHCP relay agent passes the allocated IP address to the GGSN which stores it in the corresponding PDP 
context. The GGSN then initiates a PDP context modification procedure by sending an Update PDP Context 
Request to the appropriate SGSN with the End User Address information element set to the allocated IP address. 

1 l)The SGSN sends a Modify PDP Context Request to the MT with the allocated IP address in the PDP Address 
information element. The MT acknowledges by sending a Modify PDP Context Accept to the SGSN. 
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12) The SGSN sends an Update PDP Context Response to the GGSN. The PDP context has been successfully 
updated with the allocated IP address. 

EXAMPLE: In the following example a successful PDP context activation with use of DHCP from end to end 
is shown. 
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1 4 Internet Hosted Octet Stream Service (IHOSS) 

Void. 



15 Interworking between Packet Domains 

The primary reason for the interworking between Packet Domains is to support roaming subscribers as described in 
TS 23.060. The general model for Packet Domain interworking is shown in figure 21. 
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Figure 21 : General interworking between Packet Domains to support roaming subscribers. 

For roaming subscribers that have a PDP address allocated from the HPLMN a forwarding route between the HPLMN 
and the VPLMN is created. This route is used for both mobile terminated and mobile originated data traffic. The 
communication is done via the BGs (Border Gateways) as described in 3GPP TS 23.060. 

The procedures to set the link between the SGSN in the VPLMN and the GGSN in the HPLMN are described in 3GPP 
TS 23.060. 

The inter-PLMN link may be any packet data network or dedicated link as described in 3GPP TS 23.060. The PLMN 
operators may have a dedicated inter-PLMN link to fulfil the QoS requirements of a certain protocol. 



15.1 Security Agreements 



Each PLMN operator may support IPsec (RFC 1825) and accompanying specifications for authentication (RFC 1826) 
and encryption (RFC 1827) as a basic set of security functionality in its border gateways. The PLMN operators may 
decide to use other security protocols based on bilateral agreements. 



15.2 Routing protocol agreements 



Each PLMN operator may support BGP (RFC 1771) as a basic set of routing functionality in its border gateways. The 
PLMN operators may decide to use other routing protocols based on bilateral agreements. 



15.3 Charging agreements 



Sharing the cost of the inter-PLMN link is subject to the agreement between the PLMN operators. 

There may be a requirement to collect charging information in the Border Gateway (see figure 21 in clause 15) and this 
is down to the normal interconnect agreement between PLMN and PDN operators. 
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1 6 Usage of RADIUS on Gi interface 

A GGSN may, on a per APN basis, use RADIUS authentication to authenticate a user and RADIUS accounting to 
provide information to an AAA (Authentication, Authorization and Accounting) server. 

16.1 RADIUS Authentication 

RADIUS Authentication shall be used according to RFC2865 [38]. 

The RADIUS client function may reside in a GGSN. When the GGSN receives a Create PDP Context request message 
the RADIUS client function may send the authentication information to an authentication server, which is identified 
during the APN provisioning. 

The authentication server checks that the user can be accepted. The response (when positive) may contain network 
information, such as an IP address for the user. 

The information delivered during the Radius authentication can be used to automatically correlate the users identity (the 
MSISDN or IMSI) to the IP-address, assigned/confirmed by the GGSN or the authentication server respectively. The 
same procedure applies, in case of sending the authentication to a 'proxy' authentication server. 

RADIUS Authentication is only applicable to the primary PDP context. When the GGSN receives an Access-Accept 
message from the authentication server it shall complete the PDP context activation procedure. If Access-Reject or no 
response is received, the GGSN shall reject the PDP Context Activation attempt with a suitable cause code, e.g. User 
Authentication failed. 

16.2 RADIUS Accounting 

RADIUS Accounting shall be used according to RFC 2866 [39]. 

The RADIUS accounting client function may reside in a GGSN. The RADIUS accounting client may send information 
to an accounting server, which is identified during the APN provisioning. The accounting server may store this 
information and use it to automatically identify the user. This information can be trusted because the GPRS network has 
authenticated the subscriber (i.e. SIM card and possibly other authentication methods). 

RADIUS Accounting-Request Start and Stop messages may be used during both primary and secondary PDP context 
activation and deactivation procedures respectively. 

The use of Accounting-Request STOP and in addition the Accounting ON and Accounting OFF messages may be used 
to ensure that information stored in the accounting server is synchronised with the GGSN information. 

If the AAA server is used for IP address assignment, then, upon reception of a RADIUS Accounting-Request STOP 
message for all PDP contexts associated to a session defined by APN and IMSI or MSISDN, the AAA server may make 
the associated IP address available for assignment. 

In order to avoid race conditions, the GGSN shall include a 3GPP Vendor-Specific sub-attribute "Session Stop 
indicator" when it sends the Accounting-Request STOP for the last PDP context of a PDP session and the PDP session 
is terminated (i.e. the IP address and all GTP tunnels can be released). The AAA server shall not assume the PDP 
session terminated until an Accounting-Request STOP with the Session Stop indicator is received. 
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16.3 Authentication and accounting message flows 
16.3.1 IPPDPtype 

The figure 14 represents the RADIUS message flows between a GGSN and an Authentication, Authorization and 
Accounting (AAA) server. 
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NOTE 1 : If some external applications require RADIUS Accounting request (Start) information before they can 
process user packets, then the selected APN (GGSN) may be configured in such a way that the GGSN 
drops user data until the Accounting Response (START) is received from the AAA server. Both 
Authentication and Accounting servers may be optional and separately configured for each APN. 

NOTE 2: Separate accounting and authentication servers may be used. 

NOTE 3: The Access-Request message shall be used for primary PDP context only. 

Figure 14: RADIUS message flow for PDP type IP (successful user authentication case) 
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When a GGSN receives a Create PDP Context Request message for a given APN, the GGSN may (depending on the 
configuration for this APN) send a RADIUS Access-Request to an AAA server. The AAA server authenticates and 
authorizes the user. If RADIUS is also responsible for IP address allocation the AAA server shall return the allocated IP 
address in the Access- Accept message. 

Even if the GGSN was not involved in user authentication (e.g. transparent network access mode), it may send a 
RADIUS Accounting-Request START message to an AAA server. This message contains parameters, e.g. the tuple 
which includes the user-id and IP address, to be used by application servers (e.g. WAP gateway) in order to identify the 
user. This message also indicates to the AAA server that the user session has started. User data forwarding at the GGSN 
may not be allowed before the Accounting Response START is received. If this is the case, the GGSN drops user data 
until the Accounting Response START is received. This is configurable per APN. 

When the GGSN receives a Delete PDP Context Request message and providing a RADIUS Accounting-Request 
START message was sent previously, the GGSN shall send a RADIUS Accounting-Request STOP message to the 
AAA server, which indicates the termination of this particular user session. The GGSN shall immediately send a Delete 
PDP context response, without waiting for an Accounting-Response STOP message from the AAA server. 

The AAA server shall deallocate the IP address (if any) initially allocated to the subscriber, if there is no session for the 
subscriber. 

Accounting-Request ON and Accounting-Request OFF messages may be sent from the GGSN to the AAA server to 
ensure the correct synchronization of the session information in the GGSN and the AAA server. 

The GGSN may send an Accounting-Request ON message to the AAA server to indicate that a restart has occurred. 
The AAA server may then release the associated resources. 

Prior to a scheduled restart, the GGSN may send Accounting-Request OFF message to the AAA server. The AAA 
server may then release the associated resources. 

If an Access-Challenge is sent to the GGSN when an Access-Request message is pending and when IP PDP type is 
used, the GGSN shall silently discard the Access-Challenge message and it shall treat an Access-Challenge as though it 
had received an Access-Reject instead [38]. 

16.3.2 PPP PDP type 

The figure 15 describes the RADIUS message flows between a GGSN and an Authentication, Authorization and 
Accounting (AAA) server for the case where PPP is terminated at the GGSN. The case where PPP is relayed to an LNS 
is beyond the scope of this specification. 
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NOTE 1: Separate accounting and Authentication servers may be used. 

NOTE 2: Actual messages depend on the used authentication protocol (e.g. PAP, CHAP) 

NOTE 3: User data may not be allowed before the Accounting Response (START) is received. If this is the case, 
the GGSN drops user data until the Accounting Response (START) is received. 

NOTE 4: An LCP termination procedure may be performed. Either the MS or the GGSN may initiate the context 
deactivation. 

NOTE 5: The Access-Request message shall be used for primary PDP context only. 

NOTE 6: Network Initiated deactivation 

NOTE 7: User Initiated deactivation 

Figure 15: RADIUS message flow for PDP type PPP (successful user authentication case) 
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When a GGSN receives a Create PDP Context Request message for a given APN, the GGSN shall immediately send a 
Create PDP context response back to the SGSN. After PPP link setup, the authentication phase may take place. During 
Authentication phase, the GGSN sends a RADIUS Access-Request to an AAA server. The AAA server authenticates 
and authorizes the user. If RADIUS is also responsible for IP address allocation the AAA server shall return the 
allocated IP address in the Access- Accept message (if the user was authenticated). 

If the user is not authenticated, the GGSN shall send a Delete PDP context request to the SGSN. 

Even if the GGSN was not involved in user authentication (e.g. for PPP no authentication may be selected), it may send 
a RADIUS Accounting-Request START message to an AAA server. This message contains parameters, e.g. a tuple 
which includes the user-id and IP address, to be used by application servers (e.g. WAP gateway) in order to identify the 
user. This message also indicates to the AAA server that the user session has started, and the QoS parameters associated 
to the session. 

User data forwarding at the GGSN may not be allowed before the Accounting Response START is received. If this is 
the case, the GGSN drops user data until the Accounting Response START is received. This is configurable per APN. 

When the GGSN receives a Delete PDP Context Request message and providing a RADIUS Accounting-Request 
START message was sent previously, the GGSN shall send a RADIUS Accounting-Request STOP message to the 
AAA server, which indicates the termination of this particular user session. The GGSN shall immediately send a Delete 
PDP context response, without waiting for an Accounting-Response STOP message from the AAA server. 

The AAA server shall deallocate the IP address (if any) initially allocated to the subscriber. 

Accounting-Request ON and Accounting-Request OFF messages may be sent from the GGSN to the AAA server to 
ensure the correct synchronization of the session information in the GGSN and the AAA server. 

The GGSN may send an Accounting-Request ON message to the AAA server to indicate that a restart has occurred. 
The AAA server may then release the associated resources. 

Prior to a scheduled restart, the GGSN may send Accounting-Request OFF message to the AAA server, the AAA server 
may then release the associated resources. 

If an Access-Challenge is sent to the GGSN when using PPP PDP type, the GGSN shall handle it by PPP CHAP 
providing PPP CHAP was the selected Authentication protocol. If CHAP authentication was not selected, 
authentication shall fail [38]. 

1 6.4 List of RADIUS attributes 

The following tables describe the actual content of the RADIUS messages exchanged between the GGSN and the AAA 
server. Other RADIUS attributes may be used as defined in RADIUS RFC(s). Unless otherwise stated, when the 
encoding scheme of an attribute is specified as UTF-8 encoding, this shall be interpreted as UTF-8 hexadecimal 
encoding. 



ETSI 



3GPP TS 29.061 version 4.2.0 Release 4 



34 



ETSI TS 129 061 V4.2.0 (2001-09) 



1 6.4.1 Access-Request message (sent from the GGSN to AAA server) 

The table 1 describes the attributes of the Access-Request message. 

Table 1 : The attributes of the Access-Request message 



Attr# 


Attribute Name 


Description 


Content 


Presence 
Requirement 


1 


User-Name 


Username is provided by the user (extracted from 
the Protocol Configuration Options (PCO) field of 
the Create PDP Context Request message) or 
PPP authentication phase (if PPP PDP type is 
used). If no username is available a generic 
username, configurable on a per APN basis, shall 
be present. 


String 


Mandatory 


2 


User-Password 


User password provided by the user if PAP is 
used (extracted from the PCO field of the Create 
PDP Context Request message) or PPP 
authentication phase (if PPP PDP type is used). If 
no password is available a generic password, 
configurable on a per APN basis, shall be present. 


String 


Conditional 
Note 1 


3 


CHAP-Password 


User password provided by the user if CHAP is 
used (extracted from the PCO field of the Create 
PDP Context Request message) or PPP 
authentication phase (if PPP PDP type is used). 


String 


Conditional 
Note 2 


4 


NAS-IP-Address 


IP address of the GGSN for communication with 
the AAA server. 


IPv4 


Conditional 
Note 3 


32 


NAS-Identifier 


Hostname of the GGSN for communication with 
the AAA server. 


String 


Conditional 
Note 3 


6 


Service-Type 


Indicates the type of service for this user 


Framed 


Optional 


7 


Framed-Protocol 


Indicates the type of protocol for this user 


7 (GPRS PDP 
Context) 


Optional 


8 


Framed-IP-Address 


IP address allocated for this user 


IPv4 


Conditional 


9 


Framed-IP-Netmask 


Netmask for the user IP address 


IPv4 


Conditional 


30 


Called-Station-ld 


Identifier for the target network 


APN (UTF-8 
encoded) 


Mandatory 


31 


Calling-Station-Id 


Identifier for the MS 


MSISDN in 
international 
format according 
to 3GPP TS 
23.003, UTF-8 
encoded 
decimal. Note 
that there are no 
leading 
characters in 
front of the 
country code. 


Mandatory 


60 


CHAP-Challenge 


Challenge if CHAP is used (extracted from the 
PCO field of the Create PDP Context Request 
message) or PPP authentication phase (if PPP 
PDP type is used). 


String 


Conditional 
Note 2 


61 


NAS-Port-Type 


Port type for the GGSN 


As per RFC 
2865 


Optional 


26/10415 


3GPP Vendor- 
Specific 


Sub-attributes according sub-clause 16.4.7 


See sub-clause 
16.4.7 


Optional 
except sub- 
attribute 3 
which is 
conditional 


NOTE 1 : Shall be present if PAP is used. 

NOTE 2: Shall be present if CHAP is used. 

NOTE 3: Either NAS-IP- Address or NAS-Identifier shall be present. 
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1 6.4.2 Access-Accept (sent from AAA server to GGSN) 

The table 2 describes the attributes of the Access- Accept message. 

Table 2: The attributes of the Access-Accept message 



Attr# 


Attribute Name 


Description 


Content 


Presence 
Requirement 


1 


User-Name 


Username received in the Access-Request message or a 
substitute username provided by the AAA server. If the 
User-Name has been received in the Access-Accept 
message, this user-name shall be used in preference to 
the above 


String 


Optional 


6 


Service-Type 


Indicates the type of service for this user 


Framed 


Optional 


7 


Framed-Protocol 


Indicates the type of protocol for this user 


7 (GPRS 

PDP 

Context) 


Optional 


8 


Framed-IP-Address 


IP address allocated for this user, if the AAA server is 
used to allocate IP address. 


IPv4 


Conditional 


9 


Framed-IP-Netmask 


Netmask for the user IP address, if the AAA server is 
used to allocate IP netmask. 


IPv4 


Conditional 


12 


Framed-IP-MTU 


MTU for the user towards this particular APN, MTU shall 
be less or equal to 1 500 


String 


Optional 


25 


Class 


Identifier to be used in all subsequent accounting 
messages. 


String 


Optional 
(NOTE 4) 


27 


Session-Timeout 


Indicates the timeout value (in seconds) for the user 
session 


32 bit 

unsigned 

Integer 


Optional 


28 


Idle-Timeout 


Indicates the timeout value (in seconds) for idle user 
session 


32 bit 

unsigned 

Integer 


Optional 


26/31 1 


MS- primary-DNS-server 


Contains the primary DNS server address for this APN 


Ipv4 


Optional 


26/31 1 


MS-Secondary-DNS- 
Server 


Contains the secondary DNS server address for this 
APN 


IPv4 


Optional 


26/311 


MS-Primary-NBNS- 
Server 


Contains the primary NetBios name server address for 
this APN 


IPv4 


Optional 


26/31 1 


MS-Secondary-NBNS- 
Server 


Contains the secondary NetBios server address for this 
APN 


IPv4 


Optional 


NOTE 4: The presence of this attribute is conditional upon this attribute being received in the Access- Accept message 



1 6.4.3 Accounting-Request START (sent from GGSN to AAA server) 

The table 3 describes the attributes of the Accounting-Request START message. 

Table 3: The attributes of the Accounting-Request START message 



Attr# 


Attribute Name 


Description 


Content 


Presence 
Requirement 


1 


User-Name 


Username provided by the user (extracted from 
the PCO field of the Create PDP Context Request 
message) or PPP authentication phase (if PPP 
PDP type is used). If no username is available a 
generic username, configurable on a per APN 
basis, shall be present. If the User-Name has 
been received in the Access-Accept message, 
this user-name shall be used in preference to the 
above 


String 


Optional 


4 


NAS-IP-Address 


GGSN IP address for communication with the 
AAA server. 


IPv4 


Conditional 
Note 3 


32 


NAS-ldentifier 


Hostname of the GGSN for communication with 
the AAA server. 


String 


Conditional 
Note 3 


6 


Service-Type 


Indicates the type of service for this user 


Framed 


Optional 


7 


Framed Protocol 


Indicates the type of protocol for this user 


7 (GPRS PDP 
Context) 


Optional 
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8 


Framed-IP-Address 


User IP address 


IPv4 


Mandatory 


25 


Class 


Received in the access accept 


String 


Conditional 
(NOTE 4) 


30 


Called-Station-ld 


Identifier for the target network 


APN (UTF-8 
encoded) 


Mandatory 


31 


Calling-Station-Id 


Identifier for the MS 


MSISDN in 
international 
format according 
to 3GPP TS 
23.003, UTF-8 
encoded 
decimal. Note 
that there are no 
leading 
characters in 
front of the 
country code. 


Mandatory 


40 


Acct-Status-Type 


Type of accounting message 


START 


Mandatory 


41 


Acct-Delay-Time 


Indicates how many seconds the GGSN has been 
trying to send this record for, and can be 
subtracted from the time of arrival on the AAA 
server to find the approximate time (in seconds) 
of the event generating this Accounting-Request. 


32 unsigned 
integer 


Optional 


44 


Acct-Session-ld 


User session identifier. 


GGSN IP 
address and 
Charging-ID 
concatenated in 
a UTF-8 
encoded 
hexadecimal. 
NOTE: The 
GGSN IP 
address is the 
same as that 
used in the 
GCDRs. 


Mandatory 


45 


Acct-Authentic 


Authentication method 


RADIUS or 
LOCAL 


Optional 


61 


NAS-Port-Type 


Port type for the GGSN 


As per RFC 
2865 


Optional 


26/10415 


3GPP Vendor- 
Specific 


Sub-attributes according sub-clause 16.4.7. 


See sub-clause 
16.4.7 


Optional 
except sub- 
attribute 3 
which is 
conditional 


NOTE 3: Either NAS-IP- Address or NAS-Identifier shall be present. 

NOTE 4: The presence of this attribute is conditional upon this attribute being received in the Access- Accept message 



1 6.4.4 Accounting Request STOP (sent from GGSN to AAA server) 

The table 4 describes the attributes of the Accounting-Request STOP message. 

Table 4: The attributes of the Accounting-Request STOP message 



Attr# 


Attribute Name 


Description 


Content 


Presence 
Requirement 


1 


User-Name 


Username provided by the user (extracted from 
the PCO field of the Create PDP Context Request 
message) or PPP authentication phase (if PPP 
PDP type is used). If no username is available a 
generic username, configurable on a per APN 
basis, shall be present. If the User-Name has 
been received in the Access-Accept message, this 
user-name shall be used in preference to the 


String 


Optional 
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above 






4 


NAS-IP-Address 


IP address of the GGSN for communication with 
the AAA server. 


IPv4 


Conditional 
Note 3 


32 


NAS-ldentifier 


Hostname of the GGSN for communication with 
the AAA server. 


String 


Conditional 
Note 3 


6 


Service-Type 


Indicates the type of service for this user 


Framed 


Optional 


7 


Framed Protocol 


Indicates the type of protocol for this user 


7 (GPRS PDP 
Context) 


Optional 


8 


Framed-IP-Address 


User IP address 


IPv4 


Mandatory 


25 


Class 


Received in the access accept 


String 


Optional 
(NOTE 4) 


30 


Called-Station-ld 


Identifier for the target network 


APN (UTF-8 
encoded) 


Mandatory 


31 


Calling-Station-Id 


Identifier for the MS 


MSISDN in 
international 
format 
according to 
3GPP TS 
23.003, UTF-8 
encoded. 
Note that there 
are no leading 
characters in 
front of the 
country code. 


Mandatory 


40 


Acct-Status-Type 


Indicates the type of accounting request 


STOP 


Mandatory 


41 


Acct-Delay-Time 


Indicates how many seconds the GGSN has been 
trying to send this record for, and can be 
subtracted from the time of arrival on the AAA 
server to find the approximate time of the event 
generating this Accounting-Request 


Second 


Optional 


42 


Acct-lnput-Octets 


GGSN counted number of octets sent by the user 
for the PDP context 


32 bit unsigned 
integer 


Optional 


43 


Acct-Output-Octets 


GGSN counted number of octets received by the 
user for the PDP context 


32 bit unsigned 
integer 


Optional 


44 


Acct-Session-ld 


User session identifier. 


GGSN IP 
address and 
Charging-ID 
concatenated in 
a UTF-8 
encoded 
hexadecimal. 
NOTE: The 
GGSN IP 
address is the 
same as that 
used in the 
GCDRs. 


Mandatory 


45 


Acct-Authentic 


Authentication method 


RADIUS or 
LOCAL 


Optional 


46 


Acct-Session-Time 


Duration of the session 


Second 


Optional 


47 


Acct-lnput-Packets 


GGSN counted number of packets sent by the 
user 


Packet 


Optional 


48 


Acct-Output- Packets 


GGSN counted number of packets received by the 
user 


Packet 


Optional 


49 


Acct-Terminate- 
Cause 


Indicate how the session was terminated 


See RFC 2866 


Optional 


61 


NAS-Port-Type 


Port type for the GGSN 


As per RFC 
2865 


Optional 


26/10415 


3GPP Vendor- 
Specific 


Sub-attributes according to sub-clause 16.4.7. 


See sub-clause 
16.4.7 


Optional 
except sub- 
attribute 3 
which is 
conditional 
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NOTE 3: Either NAS-IP- Address or NAS-Identifier shall be present. 

NOTE 4: The presence of this attribute is conditional upon this attribute being received in the Access- Accept message 



1 6.4.5 Accounting Request ON (optionally sent from GGSN to AAA server) 

The table 5 describes the attributes of the Accounting-Request ON message. 

Table 5: The attributes of the Accounting-Request ON message 



Attr# 


Attribute Name 


Description 


Content 


Presence 
Requirement 


4 


NAS-IP-Address 


IP address of the GGSN for communication with the 
AAA server. 


IPv4 


Conditional 
Note 3 


30 


Called-Station-ID 


Identifier for the target network. 


APN (UTF-8 
encoded) 


Optional 


32 


NAS-Identifier 


Hostname of the GGSN for communication with the 
AAA server. 


String 


Conditional 
Note 3 


NOTE 3: Either NAS-IP- Address or NAS-Identifier shall be present. 



1 6.4.6 Accounting Request OFF (optionally sent from GGSN to AAA 
server) 

The table 6 describes the attributes of the Accounting-Request OFF message. 

Table 6: The attributes of the Accounting-Request OFF message 



Attr# 


Attribute Name 


Description 


Content 


Presence 
Requirement 


4 


NAS-IP-Address 


IP address of the GGSN for communication with the 
AAA server. 


IPv4 


Conditional 
Note 3 


30 


Called-Station-ID 


Identifier for the target network. 


APN (UTF-8 
encoded) 


Optional 


32 


NAS-Identifier 


Hostname of the GGSN for communication with the 
AAA server. 


String 


Conditional 
Note 3 


NOTE 3: Either NAS-IP-Address or NAS-Identifier shall be present. 
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1 6.4.7 Sub-attributes of the 3GPP Vendor-Specific attribute 

The table 7 describes the sub-attributes of the 3GPP Vendor-Specific attribute of the Access-Request, Accounting- 
Request START and Accounting-Request STOP message. 

Table 7: The sub-attributes of the 3GPP Vendor-Specific attribute of the Access- Request, Accounting-Request 

START and Accounting-Request STOP message 



Sub-attr # 


Sub-attribute Name 


Description 


Presence 
Requirement 


Associated attribute 
(Location of Sub-attr) 


1 


3GPP-IMSI 


IMSI for this user 


Optional 


Access-Request, 

Accounting-Request 

START 


2 


3GPP-Charging-ld 


Charging ID for 
this PDP Context 
(this together with 
the GGSN- 
Address 
constitutes a 
unique identifier 
for the PDP 
context). 


Optional 


Access-Request, 

Accounting-Request 

START 


3 


3GPP-PDP Type 


Type of PDP 
context, e.g. IP or 
PPP 


Conditional 
(mandatory if 
attribute 7 is 
present) 


Access-Request 


4 


3GPP-CG-Address 


Charging 
Gateway IP 
address 


Optional 


Access-Request, 

Accounting-Request 

START 


5 


3GPP-GPRS-QoS- 
Profile 


QoS profile 
received 


Optional 


Access-Request, 

Accounting-Request 

START 


6 


3GPP-SGSN-Address 


SGSN IP address 
that is used by the 
GTP control plane 
for the handling of 
control messages. 
It may be used to 
identify the PLMN 
to which the user 
is attached. 


Optional 


Access-Request, 

Accounting-Request 

START 


7 


3GPP-GGSN-Address 


GGSN IP address 
that is used by the 
GTP control plane 
for the context 
establishment. It 
is the same as the 
GGSN IP address 
used in the 
GCDRs. 


Optional 


Access-Request, 

Accounting-Request 

START 


8 


3GPP-IMSI-MCC-MNC 


MCC and MNC 
extracted from the 
user's IMSI (first 5 
or 6 digits, as 
applicable from 
the presented 
IMSI). 


Optional 


Access-Request, 

Accounting-Request 

START 


9 


3GPP-GGSN- MCC- 
MNC 


MCC-MNCofthe 
network the 
GGSN belongs to. 


Optional 


Access-Request, 

Accounting-Request 

START 


10 


3GPP-NSAPI 


Identifies a 
particular PDP 
context for the 
associated PDN 
and MSISDN/IMSI 
from creation to 
deletion. 


Optional 


Access-Request, 
Accounting-Request 
START, Access- 
Request STOP 
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11 


3GPP- Session-Stop- 
Indicator 


Indicateds to the 
AAA server that 
the last PDP 
context of a 
session is 
released and that 
the PDP session 
has been 
terminated. 


Optional 


Accounting Request 
STOP 


12 


3GPP- Selection-Mode 


Contains the 
Selection mode 
for this PDP 
Context received 
in the Create PDP 
Context Request 
Message 


Optional 


Access-Request, 

Accounting-Request 

START 


13 


3GPP-Charging- 
Characteristics 


Contains the 
charging 

characteristics for 
this PDP Context 
received in the 
Create PDP 
Context Request 
Message (only 
available in R99 
and later 
releases) 


Optional 


Access-Request, 

Accounting-Request 

START 



The RADIUS vendor Attribute is encoded as follows (as per RFC 2865) 



Bits 



Octets 

1 
2 
3 
4 
5 
6 
7-n 



8 


7 


6 5 4 3 


2 1 


Type = 26 


Length = n 


Vendor id octet 1 


Vendor id octet 2 


Vendor id octet 3 


Vendor id octet 4 


String 



n>=7 

3GPP Vendor Id = 10415 

The string part is encoded as follows: 



Octets 

1 

2 

3-m 



Bits 

5 4 3 



3GPP type 



3GPP Length = m 



3GPP value 



m>=2 and m<= 248 
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The 3GPP specific attributes encoding is clarified below. 
1 - 3GPP-IMSI 



Bits 



Octets 

1 
2 
3 
4 
5 
6 
7 
8 
9-15 



8 7 6 5- 


13 2 1 


3GPP type = 


= 1 


3GPP Length 


= 15 


IMSI digitl (UTF-8 


encoded) 


IMSI digit2 (UTF-8 


encoded) 


IMSI digit3 (UTF-8 


encoded) 


IMSI digit4 (UTF-8 


encoded) 


IMSI digit5 (UTF-8 


encoded) 


IMSI digits (UTF-8 


encoded) 


IMSI digits 7-15 (UTF-8 encoded) 



3GPP Type: 1 

Length: L =17 

IMSI value: Text: 

This is the UTF-8 encoded IMSI; If the MNC is only 2 digits (e.g. MNC = 78), its encoding shall be with a leading '0', 
(e.g. "078"). 



2 - 3GPF '- Charging ID 



Octets 


Bits 
8 7 6 5 4 3 2 1 


1 


3GPP type = 2 


2 


3GPP Lengths 6 


3 


Charging ID value Octet 1 


4 


Charging ID value Octet 2 


5 


Charging ID value Octet 3 


6 


Charging ID value Octet 4 



3GPP Type: 2 

Length: 6 

Charging ID value: 32 bits unsigned integer 
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Octets 

1 
2 
3 
4 
5 
6 



Bits 

5 4 3 



3GPP type = 3 


3GPP Lengths 6 


PDP type octet 1 


PDP type octet 2 


PDP type octet 3 


PDP type octet 4 



3GPP Type: 3 
Length: 6 

PDP type value: Unsigned 32 bits integer 
PDP type octet possible values: 

= IP 

1=PPP 

4 - 3GPP- Charging Gateway address 



Bits 



Octets 

1 
2 
3 
4 
5 
6 



8 7 6 5 4 


3 2 1 


3GPP type = 


4 


3GPP Length= 


= 6 


Charging GW addr 


Octet 1 


Charging GW addr 


Octet 2 


Charging GW addr 


Octet 3 


Charging GW addr 


Octet 4 



3GPP Type: 4 

Length: 6 

Charging GW address value: Address 
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5 - 3GPP- GPRS QoS profile 



Octets 

1 

2 

3-L 



Bits 

5 4 3 



3GPP type = 5 



3GPP Lengths L 



UTF-8 encoded QoS profile 



3GPP Type: 5 

Length: 24 (release 99) or 8 (release 98) 

QoS profile value: Text 

UTF-8 encoded QoS profile syntax: 

"<Release indicator> - <release specific QoS IE UTF-8 encoding>" 

<Release indicator> = UTF-8 encoded number : 

"98" = Release 98 

"99"= Release 99 

<release specific QoS profile UTF-8 encoding> = UTF-8 encoded QoS profile for the release indicated by the 
release indicator. 

The UTF-8 encoding of a QoS IE is defined as follows: each octet is described by 2 UTF-8 encoded 
digits, defining its hexadecimal representation. The QoS profile definition is in 3G TS 24.008 

The release 98 QoS profile data is 3 octets long, which then results in a 6 octets UTF-8 encoded string, 

The release 99 QoS profile data is 1 1 octets long, which results in a 22 octets UTF-8 encoded string. 

6 - 3GPP-SGSN address 



Bits 



Octets 

1 
2 
3 
4 
5 
6 



8 


7 


6 5 4 3 


2 1 


3GPP type = 6 


3GPP Lengths 6 


SGSN addr Octet 1 


SGSN addr Octet 2 


SGSN addr Octet 3 


SGSN addr Octet 4 



3GPP Type: 6 

Length: 6 

SGSN address value: Address 
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7- 3GPV -GGSN address 



Octets 

1 
2 
3 
4 
5 
6 



Bits 

5 4 3 



3GPP type = 7 


3GPP Lengths 6 


GGSN addr Octet 1 


GGSN addr Octet 2 


GGSN addr Octet 3 


GGSN addr Octet 4 



3GPP Type: 7 

Length: 6 

GGSN address value: Address 

8 - 3GPP-IMSI MCC-MNC 





Octets 

1 
2 
3 
4 
5 
6 
7 
8 


Bits 
8 7 6 5 4 3 2 1 




3GPP type = 8 




3GPP Lengths 8 




MCC digitl (UTF-8 encoded) 




MCC digit2 (UTF-8 encoded) 




MCC digit3 (UTF-8 encoded) 




MNC digitl (UTF-8 encoded) 




MNC digit2 (UTF-8 encoded) 




MNC digit3 (UTF-8 encoded) 


3GPPType:8 

Length: 8 

MS address value: text 





This is the UTF-8 encoding of the MS MCC-MNC values. If the MNC is only 2 digits (e.g. MNC = 78), its encoding 
shall be with a leading '0', (e.g. "078"). 



9 - 3GVV -GGSN MCC-MNC 



Octets 


Bits 
8 7 6 5 4 3 2 1 


1 


3GPP type = 9 


2 


3GPP Lengths 8 


3 


MCC digitl (UTF-8 encoded) 


4 


MCC digit2 (UTF-8 encoded) 


5 


MCC digit3 (UTF-8 encoded) 


6 


MNC digitl (UTF-8 encoded) 


7 


MNC digit2 (UTF-8 encoded) 


8 


MNC digit3 (UTF-8 encoded) 
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3GPP Type: 9 

Length: 8 

GGSN address value: text 

This is the UTF-8 encoding of the GGSN MCC-MNC values. If the MNC is only 2 digits (e.g. MNC = 78), its encoding 
shall be with a leading '0', (e.g. "078")- 



10 - 3GPP-NSAPI 



Octets 

1 
2 
3 



Bits 

5 4 3 



3GPP type = 


10 


3GPP Length 


= 6 


NSAPI 



3GPP Type: 10 

Length: 3 

NSAPI value: text 

It is the value of the NSAPI of the PDP context the RADIUS message is related to. It is encoded as its hexadecimal 
representation, using 1 UTF-8 encoded digit. 



77- 3 GPP- Session Stop Indicator 



Octets 

1 
2 



Bits 



8 


7 


6 5 4 3 


2 


1 


3GPP type = 1 1 


3GPP Lengths 2 



3GPP Type: 1 1 

Length: 2 

There is no value field for this Vendor Specific Attribute. 

72 - 3GPP-Selection-Mode 



Octets 

1 
2 
3 



Bits 



8 


7 6 5 4 3 2 1 


3GPPtype = 12 


3GPP Lengths 1 


UTF-8 encoded Selection mode string 



3GPPType: 12 
Length: 3 
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Selection mode value: Text 

The format of this attribute shall be a character string consisting of a single digit, mapping from the binary value of the 
selection mode in the Create PDP Context message [24]. Where TS 29.060 provides for interpretation of the value, e.g. 
map '3' to '2', this shall be done by the GGSN. 



13 - 3 GPP- Charging-Characteristics 



Octets 

1 

2 

3-6 



Bits 

5 4 3 



3GPPtype = 13 



3GPP Lengths 6 



UTF-8 encoded Charging Characteristics value 



3GPPType: 13 

Length: 6 

Charging characteristics value: Text 



The charging characteristics is value is the value of the 2 octets value field taken from the GTP IE 
described in 29.060section 7.7.23. 

Each octet of this IE field value is represented via 2 UTF-8 encoded digits, defining its hexadecimal 
representation. 
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Annex A (informative): 
Interworking PCS1900 with PSDNs 

<VOID> 
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Annex B (informative); 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 




Apr 1999 








Transferred to 3GPP CN1 


7.0.0 




05-1999 


TSG#03 








Approved at CN#03 




3.0.0 


06-1999 


TSG#04 




001 




Access to PDNs and ISPs with the PDP-type PPP 


3.0.0 


3.1.0 


06-1999 


TSG#04 




002 




GPRS Internet Hosted Octet Stream Service (IHOSS) 


3.0.0 


3.1.0 


12-1999 


TSG#06 




003 




Clarification on the PPP LCP Negotiation for PDP Type PPP 


3.1.0 


3.2.0 


12-1999 


TSG#06 




004 




Enhancement to Numbering and Addressing to Include the APN 


3.1.0 


3.2.0 


12-1999 


TSG#06 




005 




IPCP Negotiation Interworking at the MT for Non-Transparent IP 


3.1.0 


3.2.0 


12-1999 


TSG#06 




006 




Mobile IP Issues 


3.1.0 


3.2.0 


12-1999 


TSG#06 




007 




Access to an Intranet/ISP with DHCP End to End 


3.1.0 


3.2.0 


12-1999 


TSG#06 




008 




Streamlining 


3.1.0 


3.2.0 


03-2000 


TSG#07 




009 




Specification reference section clean-up 


3.2.0 


3.3.0 


03-2000 


TSG#07 




010 




Support for the IP-Multicast protocol 


3.2.0 


3.3.0 


03-2000 


TSG#07 




011 




Correction for the support of IPv6 


3.2.0 


3.3.0 


03-2000 


TSG#07 




012 




Removal of X.25. 


3.2.0 


3.3.0 


03-2000 


TSG#07 




013 




TSG CN1 Vocabulary Alignment 


3.2.0 


3.3.0 


09-2000 


TSG#09 




014 




Corrections to MobilelP 


3.3.0 


3.4.0 


03-2001 


TSG#1 1 


NP-010044 


015 




DHCP Lease Renewal 


3.4.0 


3.5.0 


03-2001 


TSG#1 1 


NP-010044 


016 




Removal of IHOSS and OSP 


3.4.0 


3.5.0 


03-2001 


TSG#1 1 








Upgraded to Release 4 


3.5.0 


4.0.0 


06-2001 


TSG#12 


NP-010256 


018 




Clarifications on the non-transparent access mode 


4.0.0 


4.1.0 


06-2001 


TSG#12 


NP-010256 


020 




Set the use of PPP between the MT and TE as an option when 
interworking with MIPv4 


4.0.0 


4.1.0 


09-2001 


TSG#13 


NP-010530 


021 


5 


Standard method for information delivery (MSISDN; IP address...) 
between GPRS and external PDN using RADIUS 


4.1.0 


4.2.0 
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